Dynamic machine synthesis for wireless device access and management

ABSTRACT

Disclosed are techniques for effective wireless device access and management via device capability integration. A method for constructing a machine using a plurality of devices selected from a group of devices, wherein each device in the group is configurable for providing short-range wireless communication, includes the steps of: starting an application template in response to an instruction from a user; analyzing the template to determine one or more capabilities required for the machine; searching in the group for devices substantially matching at least one of the capabilities; and integrating the matching devices into the machine.

FIELD OF THE INVENTION

The present invention relates to construction of a dynamic machine (DM)for implementing effective wireless device access and management.

BACKGROUND ART

Various applications and services place more and more requirements uponpervasive devices. These often require that we use several differentoperating equipment, since it may be impossible for us to solvedifferent problems with a single equipment. Different equipment,however, require different access and management approaches, so we haveto learn to operate them before we can use them well. There are alreadywell-accepted consistent and natural approaches of access andmanagement, such as remote control and voice command, but they can onlybe used on certain equipment.

We have seen powerful machines like ATMs or Copiers that are composed ofmultiple components to perform comprehensive functions and capabilities.However, those components usually cannot be removed and reused on othermachines or for other purposes. For example, the sound system of yourcar may never work in your house, and any ATM printer would not print acopy of a memo on your PDA. The problem is that the machines areoptimized only for specific applications and that they and theircomponents are not suitable for performing other functions. Whenever newapplications come up and old machine could not help, new machines mustbe designed and manufactured and old machines are probably abandonedtogether with all components, which is but a waste of resource.

SUMMARY OF THE INVENTION

Thus, an aspect of the present invention is to provide methods andapparatus that make consistent and natural access and management methodsavailable to all possible wireless-enabled devices.

Another aspect of the present invention is to design a method that candynamically integrate various pervasive devices' capabilities to formdynamic machines capable of performing complex tasks originally handledby real machines only.

To reach these two aspects, the present inventors have designed anarchitecture and operating platform, which only have some basicrequirements on devices in order for Dynamic Machine Stack (DMS) towork.

With the present invention, simple devices can be integrated into adynamic machine (DM) by DMS so as to provide a user with integratedaccess and management methods, thereby providing true flexibility andconvenience. Thus, complex applications or service requirements can besatisfied with a set of simple devices. Devices themselves are no longertreated as individual devices but as the constituent components of a DM.

The DMS of the present invention also provides a new approach forsolving complex problems. By using dynamic machines instead of designingand manufacturing new real machines, people could just build DMs in timeof need and disassemble them when ever they are no longer needed withlittle cost.

Bluetooth is a technology and specification for the use of short-range,wireless RF communications for both voice and data. It brings aconvenient and cost-efficient way to connect various devices. Wirelessdevices described in the present application refer to those devices withat least one short-range RF module. Long distance RF module is notadopted in DMS because anything that can be called a machine is supposedto have a reasonable size that can be covered by short-rangecommunications. If some devices have to perform long-distance internalcommunication, they are usually not regarded as a machine. There arealready several short-range wireless protocols available, and Bluetoothis the preferable choice for DMS implementation.

Further advantages of the present invention include:

-   -   1) integrated device access and management methods are provided;    -   2) user configuration and operation are simplified when        performing complex tasks that require multiple devices to work        simultaneously together;    -   3) complex tasks can be handled with simple devices; and    -   4) an optimized way for resource distribution is provided.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects, features, and advantages of the presentinvention will become apparent upon further consideration of thefollowing detailed description of the invention when read in conjunctionwith the drawing figures, in which:

FIG. 1 shows a process of constructing a template;

FIGS. 2a and 2b illustrate how components are formulated from devices;

FIG. 3 is an example a flow chart for explaining an assembling processof DM;

FIG. 4 is an example used for explaining the operation of DM; and

FIG. 5 is an example used for explaining the disassembling of DM.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

The present invention provides methods and apparatus for integrating adynamic machine for the access and management of integrated wirelessdevices. The method utilizes short-range wireless communicationtechnologies to connect various devices and to integrate the functionsof the devices, so as to construct DMs that can bring true convenienceand flexibility to end users.

First, definitions of some basic concepts need to be made as follows:

-   -   1. Device: refers to an equipment with relatively simpler        structure and functions, e.g., a lamp. A PDA is also regarded as        a device because it is small and compact and provides limited        functions in spite of a plurality of its components.    -   2. Machine: It refers to an equipment made up of multiple        components that can perform complex functions. For example, a        car is a machine made up of hundreds of components. Components        themselves can be devices or machines. Component machines can be        regarded as subsets of devices.    -   3. capability: refers to the functions and the scope of the        functions that a device or a machine can provide. (In some other        articles, this is also referred to as service. To avoid        confusion, the word “capability” is chosen). For example, a        monitor can display text and graphics; additionally, it may have        varied resolution, color depth and refresh rate    -   4. property: device or machine variables that represent its        internal data or status information. Properties are dynamic or        runtime information of a device or machine that may change with        the time.    -   5. method: the way a device or machine provides for a user or        another device to manipulate it. For example, any device may        have “On/Off” method for others to turn it on/off.    -   6. event: small package of intercommunication data that devices        or machines send to each other. With events, devices can        exchange data and command without much internal knowledge about        each other.    -   7. service: a remote or local offering of information or data        from one or more devices or machines.        Dynamic Machine Stack (DMS)

DMS is the software implementation of all required functions of adynamic machine on a certain platform. A DMS must have the followingfunction or service modules:

1) Bluetooth and/or Other Wireless Protocol Support

If target platform already supports modules like Bluetooth, then noextra support is generally required in DMS. However, on systems wherewireless modules are optional, DMS must have necessary Bluetooth and/orother wireless protocol support.

Bluetooth and/or other wireless protocol support are necessary functionsof DMS.

2) Dynamic Machine Transfer Protocol (DMTP) Processing

A higher-level protocol is required for different wireless devices totalk to each other.

DMTP refers to such protocols, which enable device data exchangeindependent of underlying protocols.

DMTP processing module is the module that performs actual DMTPoperations to enable different devices' higher-layers talk to eachother.

DMTP processing function is always required by DMS.

3) Dynamic Machine Name Service (DMNS) Processing

-   -   Components in a DM need to be given easy names for human access.        And when a user issues an implicit command, the DM needs to        figure out which component the user is referring to. DMNS is        right for these jobs. A DMNS module would carry out actual        naming or resolving actions according to characteristics of the        devices or the DM , the user habits or experiences, etc. DMNS        processing is an optional function of DMS.        4) Dynamic Machine Device Pool (DMDP) Processing    -   Assistant service is needed for managing a large amount of        devices . DMDP is right to address such problems. Only systems        with enough processing power need to include this module to        manage and serve other devices. DMDP is an optional function of        DMS.        5) Dynamic Machine Markup Language (DMML) Processing

A common language is required for various devices to describe themselvesand to be understood by others. DMML language is right for this purpose.DMML module's job is for devices to store and exchange descriptionsthrough DMTP. DMML processing is a necessary function of DMS.

6. Dynamic Machine Template Language (DMTL) Runtime

A cross-platform language is required for the authoring of DMSapplications. DMTL refers to such languages. DMTL Runtime should containnecessary support functions for devices to run DMS applications, e.g.,Java Runtime.

Standards are of great importance in building a workable DMS since DMSis supposed to work on widest range of devices. Major devicemanufactures and component developers will need to establish and followopen standards so that various products could interact without anyproblem. Even for non-open or specific applications, an internalstandard is still required to make all parts work well together.

Any device that is to support Dynamic Machine Synthesis must have a DMS(Dynamic Machine Stack) installed. A certain component of the stack maybe from a designer of the operating system or from a third partydeveloper. It may be represented by a library, a plug-in, a program or adriver in files, RAM, ROM or built inside chip logic units. It isregarded as a DMS, no matter how each component is implemented.

DMS sits on top of wireless protocol stacks like Bluetooth and makes useof DMTP as device intercommunication protocol. Devices use DMML forself-descriptions in order to be understood by others. Applicationswritten in DMTL define various DM functionality and behaviors to bringtrue convenience and flexibility to users.

Below are detailed descriptions on some DMS components.

Intercommunication Between DMTP and Device:

Protocols like Bluetooth already support voice and data communication,but not all the others. Thus, higher-level protocols are required forcomplex data exchange. Moreover, DMS is supposed to work across variousstacks besides Bluetooth, therefore, higher-level protocols are requiredto enable cross-platform communication. Here DMTP refers to any one ofsuch protocols.

A real DMTP should take into account various existing wirelessprotocols' characteristics, hide the underlying details and provide astandard interface to enabled complex data exchange between variousplatforms. It could be connection-oriented or connectionless packetswitch protocol with necessary routing and fault tolerance capability.For example, if two Bluetooth devices are within a same Piconet, theycan talk to each other directly. Or if the two happen to be in differentPiconets, forwarding mechanism would help packets find their way todestiny. And if the two devices have different communication modules,gateways or routers would help data exchange between the two sides.

Note that under certain situations, e.g., all devices areBluetooth-enabled and within a same Piconet, DMTP processing moduleseems unnecessary. However for more general implementations, DMTP is amust. Even in the simplest case, DMTP would surely enhance thereliability of communication and help ease the curve of incompatibilitybetween different versions of a same kind of stack.

DMML and Device Description:

DMTP ensures devices to talk in a common way, but they must speak a samelanguage before they can understand each other. DMML refers to anypossible common language for device description. A real DMML could bebased on XML technologies, which would make it easy for possibleconnections between DMS applications and XML-based services. Each DMSdevice should bear one or more built-in DMML pages, which describe itsown capabilities, properties, events and if available, control panels,voice commands and other information necessary for device and/or humanto understand the nature of the device. A DMML page from a certaindevice is regarded as a detailed profile of that device in a readableformat. After parsing the page, further operations could be made on thisdevice party operations.

Any DMS device should have a DMML processing module whose job is toparse DMML pages obtained from other devices and send this device's ownpage to others upon query through DMTP module.

Moreover, DMML pages regarding entire DM could be generated forhigher-level management purpose when necessary. DMS Application mayinclude methods for generating the pages.

DMTL and DMS Application:

A DM is supposed to provide advanced functions beyond those componentdevices' built-in functions. It is very difficult to build devices smartenough to understand each other's capabilities and generate enhancedfunctions automatically. And there could be many ways to make use of twosimple devices. Thus special programs called DMS applications arerequired to make enhanced features available to users.

DMS applications are supposed to work across various platforms, thus aplatform-independent programming language is required, referred to asDMTL. An application written in real DMTL is supposed to work on variousplatforms. Thus necessary support must present on each platform, whichis supposed to be included in the DMTL runtime module.

Moreover, a same application is supposed to run on different sets ofdevices as long as they meet all requirements. So a DMS application isalso called a template. Any set of objects that fit the template couldrun the application. A template should contain device capabilityrequirements, necessary data and methods. The template is not determineduntil after the actual set of devices supported by the application hasbeen established.

DMNS:

Other devices could identify a certain device by its address. But auser-friendly name is required for each necessary device or component.When a user issues an implicit command, it is also needed to identifythe actual target device. DMNS refers to services that solve the aboveproblems.

A real DMNS is supposed to be an application-independent service runningon a dedicated public device, a machine or a user device. It should workin conjunction with devices to gain necessary information such asapplication and device nature, user habits or preferences as well asspatial information, so as to find proper names for devices or resolveactual device names.

A component device's name is just a temporary alias and may becomeinvalid after the disassembling of DM. However, self-learning mechanismcould be adopted in actual DMNS implementation, and that name couldpossibly be retained to improve service performance.

DMDP:

At public places as well as home or car environments, there might behundreds or even thousands of devices for public access. A DMDP refersto a service that resolves the mess with effective management means.

A real DMDP service could run on a dedicated public device or machine.DMDP could work as a broker to handle device management tasks. Whenevera DMS application is started and devices with certain capabilities arerequested, DMDP should help the application to find suitable ones. Whenthe application has finished using these devices, DMDP will helpresetting those devices for future use.

DMDP's job is to eliminate the overhead of finding a suitable devicefrom among a large number of candidates so as to simplify and speed upthe building of a DM and optimize communication performance.

Necessary Standards:

1) Device Capability Description

This is the basis of DMS, which and it can be gained throughcategorization of existing devices. For example, we can define acapability entry name as “Display” for monitors, and then under thisentry, sub-entries such as “resolution”, “color depth” and othernecessary items. The label of each entry and the valid parameter rangeshould be determined.

2) Device Property Description

Capabilities represent “static” information of a device, whileproperties reveal “dynamic” or runtime status of a device, e.g., currentresolution of a monitor. Property description standard is very similarto capability standard and can be gained through similar routine.

3) Event Description

Devices interaction could be carried out through events, i.e., messagepackets containing command or data, for devices to exchange data orcontrol one another. Event description standard is supposed to normalizedata exchange through standardized data format and parameter range.

A complete standard covering all kinds of devices could not be easilygenerated. But it is possible that a same kind of devices supports asame set of events, which is regarded as a subset of the standard. Asubset may get updated when necessary, and developers could look uplatest version for application authoring.

Any device must follow relative DMS standards, no matter open or closed,to maintain compatibility and consistency, or DMS would never work well.

Dynamic Machine Synthesis:

1) Devices Requirements:

DMS applications require DMS enabled devices, which can be all newdevices or retailored traditional ones, that they must bear requiredcomponents and functions and most important, follow DMS relatedstandards.

2) Requirement on Wireless Capability

A DMS device must come with at least one wireless module, Bluetooth, IRor others. Necessary components of DMS Stack must be installed.

3) DMS Working Mode Support

Device should support following working modes:

-   -   Stand-alone: the default mode for all the devices, that to work        independently regardless of other devices;    -   Slave: a device operates only according to commands or data sent        from other devices. Under this mode, the device works as a        component in a DM. All devices should support this mode;    -   Master: a device operates as a coordinator of a DM , i.e., it        monitors the status of multiple devices and controls their        operations according to the DMS application logic. Only devices        with strong processing power need to support master mode.        Required Logic Components of a Dynamic Machine:

Some logical components are required for a DM to work. Logicalcomponents are actually unions of component devices. The definitions ofall these components should be included in DMS application code, and acertain application is supposed to work only on sets of devices thatsatisfy application definition. The actual composition of a logiccomponent may vary from application to application. For a sameapplication and a same set of devices, the composition may also bedifferent each time.

CPU: just like a CPU to a PC, the CPU of a DM would control theoperation of the entire devices. Any device that supports master modecould become a CPU, and a CPU may include a plurality of such devices.

Control Panel: a DM must have necessary capabilities for human-computerinteraction. Control panel is supposed to combine various devices' HCIcapabilities to form one integrated interface for users to access themachine.

Main Function Body: the part that accomplishes main tasks of a DM. Itmay include one or more devices according to application definitions anddevice capabilities.

Connection Point: it is the interface of a DM to other devices, machinesor services. It may include multiple modules from multiple devices. Aconnection point is not necessary if the DM does not need to contactothers.

Dynamic Device Linking (DDL):

At programming time an application author may not know exactly whatdevices a DM would employ at runtime. He could but define the requiredcapabilities of component devices, and use dummy objects to finish DMlogic code. It is the runtime master devices' responsibility to findmatching devices and link dummy objects to real devices. And thisprocedure is called dynamic device linking.

As shown in FIG. 2A, a DM may require some capabilities from A to H. Thethree devices below happen to have all those required capabilities andthus in runtime they could be linked to proper dummy objectsrespectively, as shown in FIG. 2A. Of course it is not the only way tolink devices to objects. FIG. 2B shows another possible way for devicelinking.

DDL process is supposed to be conducted by a master device when buildinga DM. The master device should try to find available and suitabledevices around and build logic components as well as the entire DMthrough DMTP. Linked devices are set to slave-mode and start to operateaccording to command sent from CPU. A reverse process is started whenthe DM is no longer needed and all linked devices are unlinked and setto standalone mode.

DDL is an important concept in DMS programming that program logic is notwritten according to real objects but to dummy ones. It is also a veryimportant step in building a DM, that dummy objects must be linked toreal devices before application logic can really start to work.

Dynamic Machine Lifecycle:

Lifecycle represents possible steps for a dynamic machine to come intobeing, work and disappear as desired.

Concept/Idea step: a DM is supposed to help user solve some kind ofproblem with ease. So it is necessary to find a problem and conceive asolution to the problem.

Application/Authoring: the actual step to turn the solution into DMTLcode based on relative protocols and standards. Static definition on DMand runtime logic should be included in the application code.

Install Application: when a DMS application code is finished, it isnecessary to get it installed on certain DMS enabled devices before itcan start to work. An application could be pre-installed in device OS orhardware, or as an optional library, plug-in or program.

Triggering: an application needs to be triggered before it starts towork. It could be started manually by a user, or it could be startedautomatically according to user preferences, device configuration,policy, event, schedule, etc.

DDL: the assembling process that makes use of available devices toconstruct a DM. Application code may include necessary constructormethods if special actions need to be taken in the building step. If notenough device resource are available, this process fails and followingsteps would not be taken.

Work/Operation: DM works according to the logic defined in theapplication, and it should respond to a device event or a user commandto complete certain task.

Reverse DDL: the disassembling process is started either automaticallyaccording to application logic or manually by a DM user at the time whena DM is no longer needed. All component devices and resources occupiedare supposed to be released.

The application may include necessary destruction methods to performextra actions in the disassembling step.

User Feedback: application may also include certain methods to helpdirect user experiences, complaints, suggestions and other forms offeedback back to a proper receiver, which may help device manufacturers,application developers or service providers to improve DMS applicationusability, efficient and performance by repeating the above necessarysteps.

The assembling, operation, and disassembling of a dynamic machine willbe described below with reference to drawings.

FIG. 1 illustrates the process of the generation of a DMS application(template), which includes discovering problems encountered by a user,performing demand analysis, performing template design, andinstallation/operation of a template.

In FIG. 1, at step S101, a user determines a problem that cannot besolved by using any single existing device and demands for a solution.Then, at step S102, a requirement analysis is performed to find outrequired capabilities/components for the solution. In step S103, asystem design is performed, which includes defining user's interactionand data exchange among system components and between otherdevices/machines. In step S104, template programming is performed, whichis the actual coding for the solution, including capability requirementsand runtime logic, where all these capability requirements and runtimelogic can be written into a template and the template can work on allsimilar sets of devices.

An object-oriented script language DMTL is used for template authoring,which ensures cross-platform compatibility. The standards involved intemplate programming include: device capability description, deviceproperty description, device method description, and event description.

In step S105, the programmed template is installed onto a user device soas to be ready for running.

FIG. 3 illustrates the process of assembling of a DMS application,including starting a template, i.e. and application, by a user,analyzing the application, searching for required devices, constructingnecessary logical functional components, and starting to run. At stepS301, using a proper device, a user starts a template. The device mustbe wireless-communication enabled and have DMTL runtime environment,necessary processing power, and memory. At step S302, the processperforms an analysis of the template so as to determine the requiredcapabilities/components and to estimate the required processing power.At step S303, the process searches for required component. At step S304,it is determined whether DMDP is available. If the result of thedetermination is “NO”, the process goes to step S305, where an inquirymessage is broadcast, making use of DMTP for protocol-independent dataexchange. Then, at step S306, the process wait for devices to reply inDMML pages.

All devices should send back their built-in DMML pages as their reply toan inquiry message upon receiving the inquiry. The DMML pages mayinvolve: device capability description, device property description,device method description, event description, etc.

At step S307, candidate devices are filtered according to predeterminedcriterions, which include whether a device is the best, whether a deviceis satisfactory, whether a device is the cheapest, what location adevice is in, etc. then, the process goes to step S311.

If the result of determination at step S304 is “YES”, i.e. DMDP isavailable, then the process goes to step S309, where requirements aresent to a DMDP server. The DMDP provides device warehouse services fordevice management and accelerates device searching. Then, at step S310,DMDP finds proper devices and sends back the result to the user device.Then, the process goes to step S311.

At step S311, it is determined whether required devices are found. Ifthe result of step S311 is “NO”, then the process goes to step S312,where the user is prompted of failure, and the process is then aborted.If the required devices are found, the process goes to step S313, wherewireless connections to the found devices are set up and where, ifdevices with various wireless protocol stacks are involved, a gatewaymay be needed. Then, at step S314, a dynamic device linking isperformed.

At step S315, logic components of the DM are built according to templaterequirements and runtime logic definition, each component may be made upof multiple devices. These devices usually include: CPU, i.e., a devicewith enough processing power to control the DM operation, which can bethe user device that starts the template or can be another device;control panel, which is the human computer interface (HCI) part of theentire DM and is built according to the required HCI capabilitiesdefined in template; main function body, which is the part thataccomplishes the main tasks of the DM; and connection point, which isnecessary only when the DM needs to connect to other devices/machines.

At step S316, naming of components/devices is performed through DMNS,that is, necessary components/devices in the DM are named withuser-friendly names for multi-modal processing. Thus, a DM has beenbuilt.

FIG. 4 illustrates the operation process of DMS, in which the CPUperforms initialization and processes various events generated duringoperation, i.e., performs operation on relevant devices. As shown inFIG. 4, after DMML starts its work, at step S401, the CPU initializes DMand executes the portal method defined in template to initializenecessary devices and the entire DM by sending proper event packets tocomponent devices.

At step S402, an event is obtained, which can be an event generated byuser input, data exchange or device state change and which is sent toCPU.

At step S403, it is determined if a predefined processing logic isfound. If the result of step S403 is “NO”, then the process goes to stepS404, where the event is dropped.

If the predefined processing logic is found at step S403, the processgoes to step S406, where the event is processed by using the predefinedlogic of the template and what actions a component device should carryout is determined.

Then, the process goes to step S407, where the component devices arecommanded through events and CPU generates appropriate event packets toproper devices. Here the event description standards are involved.

Then, the process goes to step S408, where CPU sends event packets toproper devices through DMTP.

FIG. 5 illustrates the disassembling process of a DMS, in which the CPUperforms the disassembling, broadcasts a reset message and freesdevices. As shown in FIG. 5, at step S501, the disassembling process istriggered by a user command or a certain event, and the DM stopsworking. Then, at step S502, CPU calls a destructor method, includingfreeing resources, disconnecting from a remote server, etc. then, atstep S503, a reset event is broadcast; all component devices shouldconfirm by replying to this event and perform necessary cleaning up;event description standards are involved in this step. At step S504, theprocess waits till each component confirms.

Then, at step S505, it is determined whether a component is obtainedthrough DMDP. If the result of step S505 is “NO”, the process goes tostep S506 to broadcast another reset event. Then, at step S507, CPUperforms self-disassembling of DMS and frees the components controlledby CPU, thus finishing the disassembling process.

If the result of step S505 is “YES”, then, the process goes to stepS508, where the component device is returned to DMDP, and DMDP performsnecessary cleaning up and resetting. Then, at step S509, the user devicefrees itself to finish the disassembling process.

Advantages of DMS:

-   Natural and Consistent Device Access and Management: various devices    have various access methods. In the traditional approach, if a    device needs to support some kind of access method, it must have    appropriate modules physically installed. For example, if a    microwave oven is to support voice command, it must have a speech    recognition module. Various devices come with various remote-control    sets when put together will surely cause lots of confusions and    inconveniences. DMS provides a new solution to solve this kind of    problems. That is to try to make any access and management    capability from any device available to any others through DM    building. For example, one device's speech recognition engine could    serve other devices to make them appear speech enabled. Or a PDA    with a touch screen could display many other devices' control    panels, and a user could bring up the desired ones any time to    command target devices with that PDA without confusion.

Convenience and Flexibility: people need to do various things when theygo around but any single device could not handle all the jobs. We maycarry lots of devices all the time, which is not at all convenient. Orwe can try to invent some powerful “all-in-one” devices. In reality“all-in-one” is attractive but just not practical, for such devices arehard to build into portable forms and must be updated now and then tomeet new requirements, which is by no means flexible. With DMS, powerfulDMs can be built in time of need and users need only to carry fewpowerful master devices. There could be numerous ways to make use ofsimple devices that we do not need to tailor-make machines for specificapplications. DMS would provide people with dynamic machines that maysolve even the most complicated problems.

-   Optimized Resource Distribution: nowadays people are constantly    encountering the “80-20” problem, that you probably spend 80% of the    time working with only 20% of all the functions. But you have got to    pay for the 100%. DMS provides a possible solution to this problem    that to make those infrequently used function modules as shared    public resources. These resources can join with other devices    through DMS to perform complex tasks. Thus users can just RENT    infrequently used resources in time of need rather than BUY them and    wait for a rare chance to use them.

It is to be understood that the description and illustration ofembodiments and modifications here are for the purpose of illustratingthe principles of the present invention only, and various modificationscan be implemented by one skilled in the art without departing from thescope of the present invention.

Variations described for the present invention can be realized in anycombination desirable for each particular application. Thus particularlimitations, and/or embodiment enhancements described herein, which mayhave particular advantages to a particular application need not be usedfor all applications. Also, not all limitations need be implemented inmethods, systems and/or apparatus including one or more concepts of thepresent invention.

The present invention can be realized in hardware, software, or acombination of hardware and software. A visualization tool according tothe present invention can be realized in a centralized fashion in onecomputer system, or in a distributed fashion where different elementsare spread across several interconnected computer systems. Any kind ofcomputer system—or other apparatus adapted for carrying out the methodsand/or functions described herein—is suitable. A typical combination ofhardware and software could be a general purpose computer system with acomputer program that, when being loaded and executed, controls thecomputer system such that it carries out the methods described herein.The present invention can also be embedded in a computer programproduct, which comprises all the features enabling the implementation ofthe methods described herein, and which—when loaded in a computersystem—is able to carry out these methods.

Computer program means or computer program in the present contextinclude any expression, in any language, code or notation, of a set ofinstructions intended to cause a system having an information processingcapability to perform a particular function either directly or afterconversion to another language, code or notation, and/or reproduction ina different material form.

Thus the invention includes an article of manufacture which comprises acomputer usable medium having computer readable program code meansembodied therein for causing a function described above. The computerreadable program code means in the article of manufacture comprisescomputer readable program code means for causing a computer to effectthe steps of a method of this invention. Similarly, the presentinvention may be implemented as a computer program product comprising acomputer usable medium having computer readable program code meansembodied therein for causing a a function described above. The computerreadable program code means in the computer program product comprisingcomputer readable program code means for causing a computer to effectone or more functions of this invention. Furthermore, the presentinvention may be implemented as a program storage device readable bymachine, tangibly embodying a program of instructions executable by themachine to perform method steps for causing one or more functions ofthis invention.

It is noted that the foregoing has outlined some of the more pertinentaspects and embodiments of the present invention. This invention may beused for many applications. Thus, although the description is made forparticular arrangements and methods, the intent and concept of theinvention is suitable and applicable to other arrangements andapplications. It will be clear to those skilled in the art thatmodifications to the disclosed embodiments can be effected withoutdeparting from the spirit and scope of the invention. The describedembodiments ought to be construed to be merely illustrative of some ofthe more prominent features and applications of the invention. Otherbeneficial results can be realized by applying the disclosed inventionin a different manner or modifying the invention in ways known to thosefamiliar with the art.

What is claimed is:
 1. A method for constructing a machine using aplurality of devices selected from a group of devices, wherein eachdevice in said group of devices is configurable for providingshort-range wireless communication, the method comprising the steps of:starting an application template in response to an instruction from auser, wherein the application template comprises coding of capabilityrequirements and runtime logic; analyzing the template to determine oneor more capabilities required for the machine; searching in the groupfor devices substantially matching at least one of said capabilities;filtering devices according to predetermined criteria comprising atleast one of device rating, device cost and device location; andintegrating the filtered devices substantially matching at least one ofsaid capabilities into the machine.
 2. The method of claim 1, whereinsaid template defines the machine formed with one or more componentseach having required capabilities, and said integrating step comprises:linking devices from the group with at least one of the requiredcapabilities so as to build each of said one or more components usingthe linked devices; and integrating said one or more components intosaid machine.
 3. The method of claim 1, characterized by furthercomprising the steps of determining whether a pool processing devicecapable of performing a pool processing for said template applicationexists in said group.
 4. The method of claim 3, wherein when it isdetermined that a pool processing device exists in said group, the poolprocessing device carries out the searching step and device management.5. The method of claim 3, wherein when it is determined that no poolprocessing device exists in said group, said searching step comprises:broadcasting an inquiry message over the group; and allowing each devicein the group to respond to the inquiry message with informationassociated therewith.
 6. The method of claim 5, wherein said informationassociated with the device comprises at least one built-in page, whichdescribes at least one of capabilities of the device, properties of thedevice, and events.
 7. The method of claim 6, wherein said at least onebuilt-in page includes a detailed profile of the device written in oneor more languages common to all the devices in the group and in areadable format.
 8. The method of claim 7, wherein said profile includesinformation selected from an information group consisting of devicecapability description; device property description; device methoddescription; and event description.
 9. The method of claim 7, furthercomprising the step of generating information regarding the machine forhigher-level management.
 10. The method of claim 5, further comprisingthe step of selecting devices to be used for building the machine basedon the information associated with the device.
 11. The method of claim1, wherein the short-range wireless communication comprises infraredtransmission.
 12. The method of claim 1, wherein the short-rangewireless communication comprises a Bluetooth protocol.
 13. A computerprogram product comprising a computer usable readable non-transitorystorage medium having computer readable program code means embodiedtherein for causing means for construction of a machine using devicesselected from a group of devices, the computer readable program codemeans in said computer program product comprising computer readableprogram code means for causing a computer to: start an applicationtemplate in response to an instruction from a user, wherein theapplication template comprises coding of capability requirements andruntime logic; analyze the template to determine one or morecapabilities required for the machine; search in the group of devicesfor devices matching at least one of the capabilities; and filterdevices according to predetermined criteria comprising at least one ofdevice rating, device cost and device location; and integrate thefiltered devices matching at least one of the capabilities into themachine.
 14. An apparatus for constructing a machine using a pluralityof devices selected from a group of devices, wherein each device in thegroup of devices is configurable for providing short-range wirelesscommunication, the apparatus comprising: a processor operative to: (i)start an application template in response to an instruction from a user,wherein the application template comprises coding of capabilityrequirements and runtime logic; (ii) analyze the template to determineone or more capabilities required for the machine; (iii) search in thegroup of devices for devices matching at least one of the capabilities;(iv) filter devices according to predetermined criteria comprising atleast one of device rating, device cost and device location; and (v)integrate the filtered devices matching at least one of the capabilitiesinto the machine.
 15. An article of manufacture for constructing amachine using a plurality of devices selected from a group of devices,wherein each device in the group of device is configurable for providingshort-range wireless communication, the article of manufacturecomprising a non-transitory machine readable medium containing one ormore programs which when executed implement the steps of: starting anapplication template in response to an instruction from a user, whereinthe application template comprises coding of capability requirements andruntime logic; analyzing the template to determine the capabilitiesrequired for the machine; searching in the group for devices matching atleast one of said capabilities; filtering devices according topredetermined criteria comprising at least one of device rating, devicecost and device location; and integrating the filtered devicessearched-out in the searching step into the machine.
 16. Anon-transitory program storage device readable by machine forconstructing a dynamic machine using a plurality of devices selectedfrom a group of devices, wherein each device in the group of devices isconfigurable for providing short-range wireless communication, tangiblyembodying a program of instructions executable by the machine which whenexecuted implement the steps of: starting an application template inresponse to an instruction from a user, wherein the application templatecomprises coding of capability requirements and runtime logic; analyzingthe template to determine the capabilities required for the machine;searching in the group for devices matching at least one of saidcapabilities; filtering devices according to predetermined criteriacomprising at least one of device rating, device cost and devicelocation; and integrating the filtered devices searched-out in thesearching step into the dynamic machine.
 17. A method of assembling anequipment using a plurality of configurable devices capable of beingcommunicatively linked together, comprising: determining a problem thatcannot be solved using any single one of the plurality of devices andrequires a solution; performing a requirements analysis to find requiredcapabilities/components for the solution; performing a system designwhich includes defining a device user's interaction and data exchangeamong system components and between other ones of the plurality ofdevices; performing template programming including coding of capabilityrequirements and runtime logic written into a template; installing theprogrammed template onto a user device among the plurality of devices;assembling an equipment application by starting the template; analyzingthe template to determine the required capabilities/components and toestimate the required processing power; searching for the requiredcapabilities/components among the plurality of devices; (and) filteringthe devices according to predetermined criteria including at least oneof device rating, device cost and device location; and constructingnecessary logical functional components from foundcapabilities/components to complete assembly of the equipment.
 18. Amethod of assembling an equipment as recited in claim 17 wherein anobject-oriented script language is used for the template programming toensure cross-platform compatibility.
 19. A method of assembling anequipment as recited in claim 18 wherein standards involved in thetemplate programming include device capability description, deviceproperty description, device method description, and/or eventdescription.
 20. A method of assembling an equipment as recited in claim19 wherein each of the plurality of devices is wireless-communicationenabled and has runtime environment, necessary processing power, andmemory.
 21. A method of assembling an equipment as recited in claim 17wherein following the search for required capabilities/components, adetermination is made whether or not dynamic machine device pool (DMDP)processing is available, and if the result of the determination is “NO”,an inquiry message is broadcast to the plurality of devices, making useof dynamic machine transfer protocol (DMTP) for protocol-independentdata exchange, and the process then waits for devices to reply indynamic machine markup language (DMML) pages which may involve at leastone of the following; device capability description, device propertydescription, device method description and/or event description.
 22. Amethod of assembling an equipment as recited in claim 21 wherein inresponse to receipt of device replies, pages from the candidate devicesare filtered according to predetermined criterions including whether thedevice is the best, whether the device is satisfactory, whether thedevice is the cheapest, and/or the location of the device.
 23. A methodof assembling an equipment as recited in claim 22 wherein if the resultof the determination is YES, DMDP is available, then the process sendsthe requirements to a DMDP server which provides device warehousingservices for device management and accelerates device searching, andwhen the server finds appropriate devices, the result is sent back tothe user device for determination as to whether or not the requireddevices have been found; if the result is “NO”, the required deviceshave not been found, then the user is prompted of the failure, and theprocess is aborted; if the result is “YES”, the required devices havebeen found, connections to the found devices are set up.
 24. A method ofassembling an equipment as recited in claim 23 wherein after the devicesare set up, a dynamic device linking is performed and logic componentsof the equipment are built according to template requirements andruntime logic definition.
 25. A method of assembling an equipment asrecited in claim 24 wherein after the dynamic device linking isperformed and logic components of the equipment are built, thecomponents/devices are named with user-friendly names for multi-modalprocessing.
 26. A method as recited in claim 17 wherein the equipment isa wireless communication system using a Bluetooth protocol.
 27. A methodof assembling an equipment as recited in claim 26 wherein anobject-oriented script language is used for the template programming toensure cross-platform compatibility.
 28. A method of assembling anequipment as recited in claim 27 wherein standards involved in thetemplate programming include device capability description, deviceproperty description, device method description, and/or eventdescription.
 29. A method of assembling an equipment as recited in claim28 wherein each of the plurality of devices is wireless-communicationenabled and has runtime environment, necessary processing power, andmemory.
 30. A method as recited in claim 25 wherein the equipment is awireless communication system using a Bluetooth protocol.
 31. A methodof assembling an equipment as recited in claim 25 wherein anobject-oriented script language is used for the template programming toensure cross-platform compatibility.
 32. A method of assembling anequipment as recited in claim 31 wherein standards involved in thetemplate programming include device capability description, deviceproperty description, device method description, and/or eventdescription.
 33. A method of assembling an equipment as recited in claim25 wherein each of the plurality of devices is wireless-communicationenabled and has runtime environment, necessary processing power, andmemory.